Management of tv programs by their buffered lengths

ABSTRACT

Systems and methods are provided for managing a time-shift buffer (TSB) that is used for buffering video presentations. One such method includes receiving user input identifying a storage capacity for the TSB and modifying a storage capacity of the TSB such that it is at least substantially equal to the storage capacity identified by the user input.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. utility application havingSer. No. 10/143,647, filed on May 10, 2002, which claims priority tocopending U.S. provisional application having Ser. No. 60/290,315, filedon May 11, 2001, both of which are entirely incorporated herein byreference. Furthermore, this application is related to copending U.S.utility patent application entitled, “CHANNEL BUFFERING AND DISPLAYMANAGEMENT SYSTEM FOR MULTI-TUNER SET-TOP BOX”, which is referencedunder Scientific Atlanta docket number 7315 and has issued under U.S.Pat. No. 7,409,140 on Aug. 5, 2008, for which the inventors are ArturoRodriguez and Ramesh Nallur, which is filed on even date herewith, andwhich is entirely incorporated herein by reference.

TECHNICAL FIELD

The invention is generally related to television systems, and, moreparticularly, is related to buffering video presentations.

BACKGROUND OF THE INVENTION

Subscriber television systems are now capable of providing many servicesin addition to analog broadcast video. In implementing enhancedprogramming, the home communication terminal (“HCT”), otherwise known asthe settop box, has become an important computing device for accessingvarious video services. In addition to supporting traditional analogbroadcast video functionality, digital HCTs (or “DHCTs”) now alsosupport an increasing number of two-way digital services such asvideo-on-demand.

A DHCT is typically connected to a cable or satellite television networkand includes hardware and software for providing various services andfunctionality. In some systems, software executed by a DHCT can bedownloaded and/or updated via the subscriber television network. Theability to download software provides flexibility in adding or updatingapplications executed by the DHCT. Each DHCT also typically includes aprocessor, communication components and memory, and is connected to atelevision. While many conventional DHCTs are stand-alone devices thatare externally connected to a television, a DHCT and/or itsfunctionality may be integrated into a television or other displaydevice, as will be appreciated by those of ordinary skill in the art.

Some DHCTs include mechanisms for buffering a video presentation,including while it is being presented to a viewer. This bufferingfunctionality allows a viewer to manipulate the video presentation usingtrick mode operations such as rewind, fast-forward, pause, and play. Oneproblem with buffering functionality offered by current DHCTs is thatthe buffering capacity is fixed. When a viewer is presented with videopresentations comprising data that exceeds the fixed buffering capacity,a portion of the previously buffered data is erased or over-written inorder to accommodate the buffering of new data. For some users, thebuffering capacity offered by a DHCT is more than satisfactory. However,other users may desire additional buffering capacity. For example,viewers that typically watch longer video presentations (e.g., 3 hourmovies) may have a greater need for a larger buffer capacity thanviewers that typically watch shorter video presentations (e.g., 30minute sit-coms). Another problem with buffering functionality offeredby DHCTs is that viewers may have different preferences regardingbuffered video presentations. For example, viewers may have differentpreferences regarding whether buffered video presentations correspondingto previously displayed television channels should continue to beaccessible after a change in television channels. Based on theforegoing, there exists a need for systems and methods that addressthese and/or other problems associated with buffering videopresentations.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention can be better understood with reference tothe following drawings. The components in the drawings are notnecessarily drawn to scale, emphasis instead being placed upon clearlyillustrating the principles of the invention. In the drawings, likereference numerals designate corresponding parts throughout the severalviews.

FIG. 1 is a high-level block diagram depicting an example of asubscriber television system.

FIG. 2 is a block diagram illustrating an example of selected componentsof the DHCT depicted in FIG. 1 in accordance with one embodiment of theinvention.

FIG. 3 is a block diagram illustrating an example of selected content ofthe system memory of the DHCT depicted in FIG. 2.

FIG. 4 is a block diagram illustrating an example of a remote controlthat may be used to provide user input to the DHCT depicted in FIG. 2.

FIG. 5 is a flow chart illustrating an example of a method for managingthe buffering capacity of the DHCT depicted in FIG. 1.

FIG. 6 is a flow chart illustrating an example of a method for managingbuffering functionality of the DHCT depicted in FIG. 1.

FIG. 7 is a flow chart illustrating an example of a method for recordinga buffered video presentation by the DHCT depicted in FIG. 1.

FIG. 8 is a block diagram illustrating an example of a user interface(UI) screen that includes a list of television programs recorded by theDHCT depicted in FIG. 1.

FIG. 9 is a block diagram illustrating an example of a UI screen thatincludes a list of recording and buffering options provided by the DHCTdepicted in FIG. 1.

FIG. 10 is a block diagram illustrating an example of a UI screen thatincludes a list of buffer management options provided by the DHCTdepicted in FIG. 1.

FIG. 11 is a block diagram illustrating an example of a UI screen thatincludes a list of buffer size options provided by the DHCT depicted inFIG. 1.

FIG. 12A is a block diagram illustrating an example of a UI screen thatincludes a list of inter-channel buffering options provided by the DHCTdepicted in FIG. 1.

FIG. 12B is a block diagram illustrating another example of a UI screenthat includes a list of inter-channel buffering options provided by theDHCT depicted in FIG. 1.

FIG. 13A is a block diagram illustrating an example of a UI screen thatincludes a list of video presentations that are buffered by the DHCTdepicted in FIG. 1.

FIG. 13B is a block diagram illustrating an example of another UI screenthat includes a list of video presentations that are buffered by theDHCT depicted in FIG. 1.

FIG. 14 is a block diagram illustrating an example of a UI screen thatincludes options for sorting a list video presentations that arebuffered by the DHCT depicted in FIG. 1.

FIGS. 15A, 15B, and 15C depict non-limiting examples of Sorted BufferedPrograms List screens that may be requested by selecting respectiveoptions from the UI screen depicted in FIG. 14.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The preferred embodiments of the invention now will be described morefully hereinafter with reference to the accompanying drawings. Inparticular, preferred embodiments of managing time-shift buffers (TSBs)will be described. A TSB comprises storage media that is used forbuffering audio and/or video (A/V) data. The buffering of A/V dataallows a user of a digital home communication terminal (DHCT) to performtrick mode operations on a television presentation that is currentlybeing broadcast. Such trick mode operations may include pause,fast-rewind, fast-forward, slow-reverse, slow-forward, and/or play. Inone embodiment of the invention, a user is provided with systems formanaging one or more TSBs. Where more than one TSB is used in a DHCT,each TSB typically buffers A/V data that is output by a respectivetuner. In one embodiment, a TSB may buffer A/V data that is received bythe DHCT from a consumer electronics device such as, for example, acamcorder. The consumer electronics device may be connected to the DHCTvia a wired or wireless port. In the description that follows, FIGS. 1-4will provide an example of system components that may be used to helpimplement and/or manage a TSB. Furthermore, examples of methods formanaging TSBs are illustrated in the flow charts of FIGS. 5-7. Finally,user interface (UI) screens that may be provided in connection withmanaging a TSB are illustrated in FIGS. 8-15. Note, however, that theinvention may be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein. Furthermore,all examples given herein are intended to be non-limiting, and areprovided in order to help convey the scope of the invention.

FIG. 1 is a block diagram depicting a non-limiting example of asubscriber television system (STS) 100 in accordance with one embodimentof the invention. In this example, the STS 100 includes a headend 110and a DHCT 200 that are coupled via a network 130. The DHCT 200 istypically situated at a user's residence or place of business and may bea stand-alone unit or integrated into another device such as, forexample, the display device 140. The DHCT 200 receives signals (video,audio and/or other data) including, for example, MPEG-2 streams, amongothers, from the headend 110 through the network 130 and provides anyreverse information to the headend 110 through the network 130. Thenetwork 130 may be any suitable means for communicating televisionservices data including, for example, a cable television network or asatellite television network, among others. The headend 110 may includeone or more server devices (not shown) for providing video, audio, andtextual data to client devices such as the DHCT 200. The headend 110 andthe DHCT 200 cooperate to provide a user with television functionalityincluding, for example, television programs, an interactive programguide (IPG), and/or video-on-demand (VOD) presentations. The televisionservices are provided via the display device 140. The display device 140may be a television or any other device capable of displaying videoimages and/or playing any corresponding audio.

FIG. 2 is a block diagram illustrating selected components of a DHCT 200in accordance with one embodiment of the invention. The DHCT 200depicted in FIG. 2 is merely illustrative and should not be construed asimplying any limitations upon the scope of the preferred embodiments ofthe invention. For example, in another embodiment, a DHCT may havefewer, additional, and/or different components than illustrated in FIG.2. The DHCT 200 preferably includes a communications interface 242 forreceiving signals (video, audio and/or other data) from the headend 110through the network 130 (FIG. 1) and for providing any reverseinformation to the headend 110.

The DHCT 200 further preferably includes at least one processor 244 forcontrolling operations of the DHCT 200, an output system 248 for drivingthe display device 140, and a tuner system 245 for tuning to aparticular television channel or frequency and for sending and receivingvarious types of data to/from the headend 110. In one embodiment, theoutput system 248 may be part of the media engine 222. Tuner system 245can select from a plurality of transmission signals provided by thesubscriber television system 100. Tuner system 245 enables the DHCT 200to tune to downstream media and data transmissions, thereby allowing auser to receive digital or analog media content via the subscribertelevision system. The tuner system 245 includes, in one implementation,an out-of-band tuner for bi-directional quadrature phase shift keying(QPSK) data communication and a quadrature amplitude modulation (QAM)tuner (in band) for receiving television signals. In one embodiment, thetuner system 245 includes a plurality of tuners for receiving aplurality of video streams.

The DHCT 200 may include one or more wireless or wired communicationports 274 for receiving and/or transmitting data to other devices. Thecommunication ports 274 may include a USB (Universal Serial Bus), anEthernet, an IEEE-1394 bus, an analog video input port, a serial port,and/or a parallel port, among others. In one embodiment, the DHCT 200may receive A/V data from a consumer electronics device such as, forexample, a camcorder, via one of the communication ports 274. The DHCT200 may also include a receiver 246 for receiving externally-generateduser inputs or commands from an input device such as, for example, aremote control.

The DHCT 200 includes at least one storage device 273 for storing videostreams received by the DHCT 200. A PVR application 277, in cooperationwith the operating system 253 and the device driver 211, effects, amongother functions, read and/or write operations to the storage device 273.Note that, references herein to write and/or read operations to/from thestorage device 273, or portions thereof, will be understood to mean thatsuch operations are performed to/from the storage medium or media (e.g.,hard disks) of the storage device 273, unless indicated otherwise. Thedevice driver 211 is a software module that preferably resides in theoperating system 253. The device driver 211, under management of theoperating system 253, provides operating instructions to the storagedevice 273. The controller 279 of the storage device 273 receivesoperating instructions from the device driver 211 and implements thoseinstructions to cause read and/or write operations to a hard disk 201(i.e., hard disk 201-1 or hard disk 201-2). Furthermore, the devicedriver 211, in cooperation with the operating system 253, communicateswith the storage device controller 279 to format and/or manipulate ahard disk 201.

The storage device 273 is preferably coupled to a common bus 205 througha communication interface 275. The communication interface 275 ispreferably an integrated drive electronics (IDE) interface or a smallcomputer system interface (SCSI), although another interface such as,for example, IEEE-1394 or USB, among others, may be used. Alternatively,the storage device 273 can be externally connected to the DHCT 200 via acommunication port 274. The communication port 274 may be, for example,an IEEE-1394, a USB, a SCSI, or an IDE, among others.

In one implementation, video streams are received in DHCT 200 viacommunications interface 242 and stored in a temporary memory cache. Thetemporary memory cache may be a designated section of DRAM 252 or anindependent memory attached directly to communication interface 242. Thetemporary cache is implemented and managed to enable media contenttransfers to storage device 273. In one implementation, the fast accesstime and high data transfer rate characteristics of the storage device273 enable media content to be read from the temporary cache and writtento storage device 273 in a sufficiently fast manner. Multiplesimultaneous data transfer operations may be implemented so that whiledata is being transferred from the temporary cache to storage device273, additional data may be received and stored in the temporary cache.

The storage device 273 preferably includes a hard disk drive but may, inan alternative embodiment, include any type of storage medium, such as,for example, a magnetic, optical, or semiconductor based storage medium,among others. The storage device 273 preferably includes at least twohard disks 201-1 and 201-2 that include storage capacity correspondingto respective buffers TSB 204-1 and TSB 204-2. In an alternativeembodiment, TSB 204-1 and TSB 204-2 may be included on a single harddisk. In another embodiment, a TSB 204 (i.e., TSB 204-1 or TSB 204-2)may reside in more than one storage medium. In yet another embodiment, aTSB 204 may reside in a storage medium that is not a hard disk.

In one embodiment of the invention, the operating system 253, devicedriver 211, and controller 279 cooperate to create a file allocationtable (FAT). The FAT is where the operating system 253 storesinformation about hard disk clusters and the files associated with thoseclusters. The operating system 253 can determine where a file's data islocated by using FAT entries. A FAT entry describes the physicallocations of data for a video stream file (i.e., a file that the videostream is written to on a hard disk 201). The FAT also keeps track ofwhich clusters are free, or open, and thus available for use. To buffera downloaded video stream into the storage device 273, the PVRapplication 277, in one preferred embodiment, creates a file and filename for the video stream to be downloaded. The operating system 253, incooperation with the device driver 211, checks the FAT for an available,or writable, cluster for storing the video stream.

When an application such as PVR application 277 creates (or extends) avideo stream file, the operating system 253, in cooperation with thedevice driver 211, queries the FAT for an available cluster to beginwriting the video stream. The PVR application 277 (through communicationwith the operating system 253 and/or device driver 211) causes thecontroller 279 to write a downloaded video stream to the availablecluster under a particular video stream file name. The FAT is thenupdated with the new video stream file name corresponding to theavailable cluster. If the video stream requires more storage space thanwhat the cluster can offer, the operating system 253 queries the FAT forthe location of another available cluster to continue writing the videostream. The FAT is updated to keep track of which clusters store aparticular video stream under the given video stream file name.

A multiplicity of clusters may be required to write a file correspondingto a compressed video stream to a hard disk 201. The clusterscorresponding to one particular video stream file may or may not beadjacent or contiguous in the hard disk 201. The clusters correspondingto a particular video stream file can be fragmented throughout a harddisk storage space. As described earlier, a file allocation table (FAT)keeps track of which clusters are employed to write a downloaded videostream to a hard disk 201. A defragmentation operation may be used bythe device driver 211 to cause the clusters associated with a particularvideo stream file to be contiguous. Other preferred embodiments includeother file allocation mechanism for storing data according to thefunctions described herein.

The DHCT 200 preferably comprises a signal processing system 214 whichincludes a demodulating system 213 and a transport demultiplexing andparsing system 215 (herein referred to as demultiplexing system 215).The components of signal processing system 214 are preferably capable ofQAM demodulation, forward error correction, demultiplexing MPEG-2transport streams, and parsing elementary streams. One or more of thecomponents of the signal processing system 214 can be implemented withsoftware, a combination of software and hardware, or preferably inhardware.

The demodulating system 213 comprises functionality for demodulatinganalog or digital transmission signals. For instance, demodulatingsystem 213 can demodulate a digital transmission signal in a carrierfrequency that was modulated, among others, as a QAM-modulated signal.When tuned to a carrier frequency corresponding to an analog TV signal,demultiplexing system 215 is bypassed and the demodulated analog TVsignal that is output by demodulating system 213 is instead forwarded toanalog video decoder 216. Analog video decoder 216 converts the analogTV signal into a sequence of digitized pictures and their respectivedigitized audio. The digitized pictures and respective audio that areoutput by analog video decoder 216 are forwarded to the compressionengine 217.

The compression engine 217 processes the sequence of digitized picturesand digitized audio and converts them into compressed video and audiostreams, respectively. The compressed video and audio streams areproduced in accordance with the syntax and semantics of a designatedaudio and video coding method, such as, for example, MPEG-2, so thatthey can be interpreted by video decoder 223 and audio decoder 225 fordecompression and reconstruction at a future time. Each compressedstream consists of a sequence of data packets containing a header and apayload. Each header contains a unique packet identification code, orPID, associated with the respective compressed stream.

The compression engine 217 multiplexes the audio and video compressedstreams into a transport stream, such as, for example, an MPEG-2transport stream. Furthermore, the compression engine 217 can compressaudio and video data corresponding to multiple video streams in parallel(e.g., multiple analog TV signals received by multiple tuners) and canmultiplex the respective audio and video compressed streams into asingle transport stream. The compression engine 217 may use a dedicatedlocal memory module (not shown) for storing data before, during, and/orafter processing by the compression engine 217. The compressed streamsoutput by compression engine 217 are provided as input to signalprocessing system 214.

The demultiplexing system 215 of the signal processing system 214interprets sequence and picture headers and annotates their locationswithin their respective compressed stream. Annotating the location ofsequence and picture headers facilitates the implementation of trickmode operations on a compressed stream. An analog video stream (e.g.,corresponding to a TV presentation) that is received via a tuned analogtransmission channel can be output as a transport stream by signalprocessing system 214 and stored in storage device 273. A compressedstream may be also output by signal processing system 214 and presentedas input to media engine 222. The video decoder 223 and the audiodecoder 225 of the media engine 222 can decompress the compressed streamfor subsequent output to the display device 140 (FIG. 1).

The demultiplexing system 215 may include means for MPEG-2 transportdemultiplexing. When tuned to carrier frequencies carrying a digitaltransmission signal, demultiplexing system 215 extracts data packetscorresponding to desired video streams for further processing.Therefore, the demultiplexing system 215 may preclude further processingof data packets corresponding to unwanted video streams. Thedemultiplexing system 215 parses (i.e., reads and interprets) desiredvideo streams to interpret sequence headers and picture headers, anddeposits the video streams into DRAM 252. The processor 244 then causesthe video streams to be transferred from DRAM 252 to the storage device273.

A compressed video stream corresponding to a tuned carrier frequencycarrying a digital transmission signal can be output as a transportstream by signal processing system 214 and stored in storage device 273.A packetized compressed stream can also be output by signal processingsystem 214 and presented as input to media engine 222. The video decoder223 and/or audio decoder 223 of the media engine 222 may decompress thecompressed stream for subsequent output to the display device 140.

One having ordinary skill in the art will appreciate that signalprocessing system 214 may include other components not shown, includingmemory, decryptors, samplers, digitizers (e.g., analog-to-digitalconverters), and multiplexers, among others. Further, other embodimentswill be understood, by those having ordinary skill in the art, to bewithin the scope of the preferred embodiments of the invention. Forexample, analog signals (e.g., NTSC) may bypass one or more elements ofthe signal processing system 214 and may be forwarded directly to theoutput system 248. In addition, data that is output by one DHCTcomponent (e.g., signal processing system 214) may be temporarily storedin DRAM 252 prior to being received as input by another DHCT component(e.g., media engine 222 or analog video decoder 216). It will also beunderstood by those having ordinary skill in the art that components ofsignal processing system 214 can be located in different areas of theDHCT 200.

In one embodiment of the invention, a plurality of tuners and respectivedemodulating systems 213, demultiplexing systems 215, and signalprocessing systems 214 may simultaneously receive and process aplurality of respective broadcast digital video streams. Alternatively,a single demodulating system 213, a single demultiplexing system 215,and a single signal processing system 214, each with sufficientprocessing capabilities may be used to process a plurality of digitalvideo streams that are received by a plurality of respective tuners.

In yet another embodiment, a first tuner in tuning system 245 receivesan analog video signal corresponding to a first video stream and asecond tuner simultaneously receives a digital compressed streamcorresponding to a second video stream. The first video stream isconverted into a digital format. The second video stream (or acompressed digital version thereof) is forwarded to the storage device273 for storage on a hard disk 201. Data annotations for each of the twostreams are performed to facilitate future retrieval of the videostreams from the storage device 273. The first video stream and/or thesecond video stream may also be forwarded to media engine 222 fordecoding and subsequent presentation via display device 140 (FIG. 1).

A plurality of compression engines 217 may also be used tosimultaneously compress a plurality of analog video streams.Alternatively, a single compression engine 217 with sufficientprocessing capabilities may be used to compress a plurality of analogvideo streams. Compressed digital versions of respective analog videostreams may be forwarded to the storage device 273 for storage on a harddisk 201. Data annotations for each of the video streams may beperformed to facilitate future retrieval of the video streams from thestorage device 273. Depending on requirements in effect, only a subsetof compressed video streams may be forwarded to the storage device 273.Any of the received video streams may also be simultaneously forwardedto media engine 222 for decoding and subsequent presentation via thedisplay device 140.

FIG. 3 is a block diagram illustrating selected components stored in thesystem memory 249 of the DHCT 200 (FIG. 2), in accordance with onepreferred embodiment. The system memory 249 described herein is merelyillustrative and should not be construed as implying any limitationsupon the scope of the invention. In one implementation, system memory249 includes flash memory 251 and dynamic random access memory (DRAM)252 for storing various applications, modules and data for execution anduse by the processor 244. In an alternative embodiment, system memory249 may include additional, fewer, and/or different types of memory.

Basic functionality of the DHCT 200 is provided by an operating system253 that is primarily stored in flash memory 251. The operating system253 includes at least one resource manager 350 that provides aninterface to and coordination of resources of the DHCT 200 such as, forexample, computing resources. One or more software applications, hereinreferred to as applications, are executed by utilizing the computingresources in the DHCT 200. Applications stored in flash memory 251 orDRAM 252 are executed by processor 244 under the auspices of theoperating system 253. Data required as input by an application is storedin DRAM 252 or flash memory 251 and read by processor 244 as neededduring the course of the application's execution. Input data may be datastored in DRAM 252 by a secondary application or other source, eitherinternal or external to the DHCT 200. Data generated by an applicationis stored in DRAM 252 by processor 244 during the course of theapplication's execution.

An application referred to as navigator 360 is also resident in flashmemory 251 for providing a navigation framework for services provided bythe DHCT 200. The navigator 360 registers for and in some cases reservescertain user inputs related to remote control keys such as channelup/down, last channel, favorite channel, etc. A platform library 310includes a collection of utilities useful to applications. Suchutilities may include a timer manager, a compression manager, an HTMLparser, a database manager, a widget toolkit, a string manager, andother utilities (not shown). These utilities are accessed byapplications via application programming interfaces (APIs) as necessaryso that each application does not have to incorporate these utilities.Two components of the platform library 310 that are depicted in FIG. 3are a window manager 330 and a service application manager (SAM) client320.

The window manager 330 provides a mechanism for implementing the sharingof the screen regions and user input. The window manager 330 is alsoresponsible for, as directed by one or more applications, implementingthe creation, display, and allocation of the limited DHCT 200 screenresources. The window manager 330 allows multiple applications to sharethe screen by assigning ownership of screen regions. The window manager330 communicates with resource manager 350 to coordinate availableresources (such as display memory) among different resource-consumingprocesses. Such processes may be directly or indirectly invoked by oneor more applications.

The window manager 330 also maintains, among other things, a user inputregistry 365 in DRAM 252. The user input registry 365 may be accessed todetermine which of various applications running on the DHCT 200 shouldreceive data corresponding to a user input, and in which order. As anapplication is executed, it registers a request to receive certain userinput keys or commands. When the user presses a key corresponding to oneof the commands on the remote control device, the command is received bythe receiver 246 and relayed to the processor 244. The processor 244dispatches the event to the operating system 253 where it is forwardedto the window manager 330. The window manager 330 then accesses the userinput registry 365 and routes data corresponding to the incoming commandto the appropriate application.

The SAM client 320 is a client component of a client-server system, withthe server component being located on the headend 110 (FIG. 1). A SAMdatabase 322 in DRAM 252 includes a data structure of services that arecreated and updated by the headend 110. Many television services can bedefined using the same application component, with different parameters.Television services may include, without limitation and in accordancewith one implementation, the presentation of television broadcastprograms, video-on-demand (VOD), music, and/or an interactive programguide (IPG). In general, the identification of a service includes theidentification of an executable application that provides the servicealong with a set of application-dependent parameters that indicate tothe application the service to be provided. As a non-limiting example, aservice of presenting a television program could be executed with a setof parameters to view HBO or with a separate set of parameters to viewCNN. Each association of the application component (e.g., watchTV 398)and one parameter component (HBO or CNN) represents a particular servicethat has a unique service I.D.

Applications can be downloaded into DRAM 252 at the request of the SAMclient 320, typically in response to a request by the user or inresponse to a message from the headend. In this non-limiting example,DRAM 252 contains a PVR application 277, an interactive program guide(IPG) application 370, and a video-on-demand (VOD) application 380. Itshould be clear to one with ordinary skill in the art that theseapplications are not limiting and merely serve as examples for thispresent embodiment of the invention. Furthermore, one or more DRAM 252based applications may, as an alternative embodiment, be resident inflash memory 251, or vice versa.

The PVR application 277 provides user interface (UI) screens that assistthe user in buffering, recording, and viewing video presentations. Forinstance, the PVR application 277 may be configured to provide the userwith the UI screens depicted in FIGS. 8-15. As used herein, a videopresentation may be a television presentation such as, for example, amovie, a television show, a cartoon, a news program, a sports program,or a series episode, among others. A video presentation may be receivedas a broadcast A/V signal or may be downloaded interactively via thetuner system 245. A video signal may also be received via one of thecommunication ports 274 from a consumer electronics device such as, forexample, a camcorder, a VCR, or a DVD player. The PVR application 277may be implemented in hardware, software, firmware, or a combinationthereof.

In a preferred embodiment, the PVR application 277 is implemented insoftware that is stored in a DRAM 252 and that is executed by processor244. The PVR application 277, which may comprise an ordered listing ofexecutable instructions for implementing logical functions, may beembodied in any computer-readable medium for use by or in connectionwith an instruction execution system, apparatus, or device, such as acomputer-based system, a processor-containing system, or another systemthat can fetch instructions from the instruction execution system,apparatus, or device and execute them.

The PVR application 277 provides for A/V data storage functionality byenabling the temporary writing to, and if requested, long-term recordingto the storage device 273. Through mechanisms explained below, A/V datais buffered in a TSB 204 (i.e., TSB 204-1 or TSB 204-2). In accordancewith a preferred embodiment, the PVR application 277 manages a TSB 204at the application level for each tuner and/or a local device providingA/V data. Hence, each tuner in tuner system 245 and/or local deviceattached to the DHCT 200 may have a respective TSB 204. Data that isbuffered in a TSB 204 may have been received from a remote server viathe subscriber television network 130 (FIG. 1), from a local device viaa home communication network, or from a consumer device such as, forexample, a video camera that is directly connected to the DHCT 200.

The A/V data buffered in a TSB 204 may be retained (in response to userinput) as a long-term recording or may be deleted as additional A/V datais buffered. The A/V data buffered in a TSB 204 may be deleted by, forexample, deleting a TSB management file associated with the data and/orby designating the clusters storing the A/V data as writable (foreventual write operations that overwrite the A/V data within thoseclusters).

A long-term recording will be understood to comprise A/V data that isstored for an extended period of time as determined by the user.Long-term recordings are stored in clusters that are not assigned to aTSB 204. A long-term recording may be scheduled in advance of itsbroadcast time or may be achieved by selecting a video presentationbuffered in a TSB 204 and designating it as a long-term recording. Aswill be described below, designating a video presentation as a long termrecording can occur, in one implementation, by receiving user inputselecting the video presentation from a list provided via a UI screen.The PVR application 277 responds by “flagging” the associated TSBmanagement file as corresponding to a long-term recording. Thedesignation of a video presentation as a long-term recording is relayedto the device driver 211 which may effect the removal of the clusterscontaining the video presentation from a TSB 204. In one embodiment, theremoval of clusters containing the video presentation from a TSB 204 maybe implemented by associating the clusters with a file corresponding tothe long-term recording, and by replenishing the TSB 204 with an equalnumber of clusters from a pool of available clusters. A long-termrecording may eventually be deleted from the storage device 273 inresponse to, for example, a user request. This deletion occurs, in oneimplementation, by configuring the associated non-buffer clusters aswritable, and thus eventually available for the buffering or recordingof other A/V data. In an alternative embodiment, a buffered videopresentation that is designated as a long term recording may be copiedfrom a TSB 204 to another portion of a hard disk 201 for long termstorage.

In one implementation, applications executing on the DHCT 200 work withthe navigator 360 by abiding by several guidelines. First, anapplication utilizes the SAM client 320 for the provision, activation,and suspension of services. Second, an application shares DHCT 200resources with other applications and abides by the resource managementpolicies of the SAM client 320, the operating system 253, and the DHCT200. Third, an application conforms to situations where shared resourcesare only accessible via the navigator 360. Fourth, when an applicationloses service authorization while providing a service, the applicationsuspends the service via the SAM client 320. The navigator 360 mayreactivate an individual service application when it later becomesauthorized. Finally, an application client is designed to not haveaccess to commands corresponding to certain user input keys reserved bythe navigator 360 (e.g., power, channel +/−, volume +/−, etc.).

Data and software used in providing a DHCT service to a user may bestored in one or more of the following memory resources: a data storagedevice located at a headend, a data storage device located at a customerpremises, a volatile or non-volatile memory internal to the DHCT 200,and/or a hard drive internal to the DHCT 200. For example, an executableprogram or algorithm corresponding to an operating system (OS)component, or to a client platform component, or to a client application(e.g., PVR application 277), or to respective parts thereof, may residein and/or execute out of DRAM 252 and/or flash memory 251. An executableprogram or algorithm may also reside in a storage device 273 and/or anexternal storage device and may be transferred into DRAM 252 forexecution. Likewise, data input and/or output for an executable programor algorithm may be stored in DRAM 252, in flash memory 251, in storagedevice 273, and/or in a storage device connected to the DHCT 200.

FIG. 4 depicts a non-limiting example of a remote control device 400that may be used to provide user input to the DHCT 200. The remotecontrol device 400 described herein is merely illustrative and shouldnot be construed as implying any limitations upon the scope of theinvention. Four arrow keys 410 are provided including an up arrow key411, a down arrow key 412, a left arrow key 413, and a right arrow key414. The arrow keys 410 can be used to scroll through on-screen optionsand/or to highlight an on-screen option. A select key 420 may be used toselect a currently highlighted option.

The functions of an “A” key 471, a “B” key 472, and a “C” key 473 mayvary depending on the UI screen being presented to a user at the time ofthe key's activation. For instance, when the UI screen illustrated inFIG. 9 is presented to a user, the “C” key 473 may be used to request apreviously displayed UI screen. Other remote control keys may functionas follows: a List key 430 may be used to request a list of videorecordings that are stored in storage device 273; an Info key 432 may beused to request additional information regarding a video presentation;and video control keys 421-426 may be used to control a VCR and/or torequest PVR functionality such as play (421), fast-forward (422), rewind(423), stop (424), pause (425), and record (426).

FIG. 5 is a flow chart illustrating a method for managing the bufferingcapacity of the DHCT 200 (FIG. 1). In step 501, the DHCT 200 receivesuser input identifying a desired buffering capacity for a TSB 204. As inother examples discussed below, a user input may be received via, forexample, a remote control device, and may correspond to an option thatis displayed via a UI screen. The desired buffering capacity ispreferably identified in terms of the play-time of the buffered A/Vdata. For example, a user may be able to select a one-hour bufferingcapacity if the user desires the ability to access up to one hour ofbuffered video presentations. In another embodiment, the bufferingcapacity may be identified in terms of a number of data units (e.g.,bytes) that may be buffered in a TSB 204. In yet another embodiment,buffering capacities for more than one TSB 204 may be identified by userinput.

After the user identifies a desired buffering capacity for a TSB 204,the amount of data that is buffered in a TSB 204 is limited (asindicated in step 502) such that it does not, or substantially does not,exceed the capacity that is identified by the user input. One approachfor limiting the amount of data that is buffered in a TSB 204 is toassign to the TSB a storage capacity (e.g., a certain number ofclusters) that corresponds to the user selected buffering capacity. Abuffering capacity that is identified in terms of a play-time may beimplemented based on an estimated number of data units that typicallyprovide such play-time. For example, if a user identifies a desired TSBcapacity as one-hour, then the storage capacity that is assigned to aTSB 204 may be limited to a predetermined number of bytes that isestimated to provide an average play-time of one-hour.

More than one approach may be used to manage a TSB 204 after a certainstorage capacity has been allocated to it. In one implementation, afterthe TSB is full of buffered data, then additional data being buffered inthe TSB is written over previously buffered data. The previouslybuffered data that is over-written is preferably, but not necessarily,data that had been residing in the TSB for the longest duration ascompared to other TSB content. In another implementation, after the TSBis full of buffered data, then a portion of the storage capacityallocated to the TSB is de-allocated from the TSB, and additionalstorage capacity that is equivalent to the de-allocated portion isassigned to the TSB to accommodate additional data buffering. Theportion of storage capacity that is de-allocated from the TSBpreferably, but not necessarily, contains data that had been residing inthe TSB for the longest duration as compared to other TSB content.

The PVR application 277 may be used to help maintain a user definedstorage capacity for a TSB 204. In a preferred embodiment, the storagecapacity of a TSB 204 corresponds to a portion of a hard disk 201. Ifstorage capacity is defined based on a desired play time, then acorresponding data unit capacity (e.g., in terms of bytes) may bedetermined based on an estimated data rate. For example, if a userselects a TSB storage capacity corresponding to 3 hours of play time,then assuming a constant bit rate of 2 mega bits per second (Mbps), thePVR application 277 may assign 0.9 gigabytes (GB) of storage capacity tothe TSB 204.

The PVR application 277 may track available disk space and use it tomaintain the TSB storage capacity at a desired level. For example,before the PVR application 277 effects a write operation to a TSB 204,it can query the device driver 211 (through the operating system 253) todetermine available hard disk space. After a write operation, the PVRapplication 277 can again poll the device driver 211 to get an update onavailable hard disk space.

A TSB 204 preferably comprises a plurality of clusters. The totalstorage capacity of the TSB clusters, at any one time, may be less thanor greater than the user-defined TSB storage capacity because ofvariations in the bit-rate within a video stream and between videostreams that are stored in a TSB 204. The variations, if any, of theamount of clusters in a TSB 204 will preferably represent a smallpercentage of the TSB capacity, thereby resulting in a substantiallyconstant TSB size over time.

The PVR application 277 preferably manages a TSB 204 by creating a TSBmanagement file associated with each buffered video presentation. Abuffered video presentation may include an entire broadcast videopresentation or only a portion thereof. For example, if the videopresentation Friends is broadcast from 8:00 p.m. to 8:30 p.m., then thebuffered video presentation of Friends may only include the portion thatwas broadcast between 8:15 and 8:30 p.m. The PVR application 277determines at what time the video presentation was tuned based on areal-time clock value that is forwarded by the operating system 253. ThePVR application 277 also receives program guide data from, for example,an IPG application 370 (FIG. 3). The program guide data may includestart and end times of each video presentation and may be received bythe IPG application 370 from the headend 110. The PVR application 277may use the program guide data and the values from a real-time clock tocreate TSB management files for tracking respective buffered videopresentations. The TSB management files may also be used to provide a UIscreen that includes a list of video presentations currently stored in aTSB 204. In one embodiment, a TSB management file, which may be storedin DRAM 252, can include program guide data (e.g., title and broadcasttime) as well as data representing the beginning and end time ofbuffered portions of video presentations.

FIG. 6 is a flow chart illustrating a method for managing bufferingfunctionality of the DHCT 200. In step 601, the DHCT 200 receives userinput identifying whether to enable access to buffered datacorresponding to a TV channel that was displayed prior to a change in TVchannels (i.e., whether to enable access to prior-channel buffereddata). Then in step 602, access to prior-channel buffered data isenabled or disabled accordingly.

When access to prior-channel buffered data is enabled, then a user mayhave access to buffered video presentations corresponding to two or morerespective television channels that are displayed to the user as aresult of one or more channel changes. In one implementation, a videopresentation is only buffered and/or accessible if the correspondingtelevision channel is presented to a user for more than a predeterminedtime period. In one embodiment, this predetermined time period may bespecified by user input.

As a non-limiting example, assume that a user requests that access toprior-channel buffered data be enabled, and that the user subsequentlywatches the video presentation Friends on channel 11. Then, in such ascenario, after the user effects a change of the displayed televisionchannel from channel 11 to channel 12, the user will still be able toreview the portion of Friends that was displayed on channel 11 prior tothe change to channel 12. In other words, data that is buffered prior toa change in channels is not deleted or otherwise rendered inaccessible.

If a user requests that access to a prior-channel buffered data bedisabled, then buffered video presentations corresponding to a priorchannel are deleted and/or rendered inaccessible. A video presentationmay be rendered inaccessible by, for example, deleting a correspondingTSB management file and/or by setting a flag that identifies the videopresentation as inaccessible.

In another embodiment, a user may press a certain remote control key(e.g., the buffer key 436 or the record key 426, FIG. 4) within a shorttime interval (e.g., 2 seconds) prior to invoking a change in TVchannels (e.g., via the channel +/− key 434) in order to cause a TVchannel being currently viewed to continue being buffered in a TSB 204after the change in TV channels is implemented. In this manner a user isprovided with a quick method for activating inter-channel buffering. Theactivation of inter-channel buffering via a certain remote control keymay be enabled or disabled by a user via an interactive configurationsession (e.g., by selecting a corresponding option via a UI screen).

FIG. 7 is a flow chart illustrating a method for recording a bufferedvideo presentation by the DHCT 200 (FIG. 1). In step 701, the DHCT 200provides a user with a list of buffered video presentations. Eachbuffered video presentation may correspond to either an entire videopresentation (e.g., a movie, a show, a cartoon, a series episode, etc.)or a portion thereof. In step 702, the DHCT 200 receives user inputidentifying a buffered video presentation that is to be stored as along-term recording. A long-term recording is a recording that willlikely remain stored in the DHCT 200 until it is expressly deletedpursuant to a user instruction or until it is over-written by a userscheduled recording.

After the DHCT 200 receives user input identifying a buffered videopresentation that is to be stored as a long-term recording, the DHCT 200stores the buffered video presentation as a long-term recording (asindicated in step 703). One approach for storing a buffered videopresentation as a long-term recording is to set a flag in acorresponding TSB management file identifying the video presentation assuch, and to designate the storage space containing the buffered videopresentation as not corresponding to a TSB 204 (i.e., to de-allocate thestorage space from a TSB 240-i). Additional storage space having acapacity equal to the size of the de-allocated storage space may beallocated to the TSB 204 to maintain a desired buffering capacity. Inanother embodiment, a video presentation that is buffered in a TSB 204may be converted to a long-term recording by being copied to anotherportion of a hard disk 201.

FIG. 8 depicts a non-limiting example of a Recorded Programs List (RPL)screen 800 that contains a list of recorded video presentations. The RPLscreen 800 may be presented by PVR application 277 in response to userinput that may be provided via, for example, the activation of the Listkey 430 (FIG. 4). The PVR application 277 may retrieve information froma PVR database 278, as needed, for presentation via the RPL screen 800.Furthermore, as in other UI screens, the PVR application 277 may work incooperation with window manager 330 to present a user with a UI screenthat is formatted in accordance with configuration data that is storedin DRAM 252.

A recorded programs list 860 contains recording entries corresponding torecorded video presentations. Each recording entry in the recordedprograms list 860 includes information such as the title of a recordedvideo presentation, the date it was recorded, the start time of therecording, and the length (i.e., play time) of the recording. In oneembodiment, the arrow keys 410 (FIG. 4) can be used to scroll throughthe recorded programs list 860 and to highlight a desired recordingentry.

The heading area 802 contains a heading for the RPL screen 800. In thisexample, the heading area contains the heading “Recorded Programs List.”The bottom area 850 of RPL screen 800 contains information about thecurrent functions of relevant keys on the remote control device 400(FIG. 4). As suggested in bottom area 850, the play key 421 may be usedto request the playing of a video presentation corresponding to acurrently highlighted recording entry, the “B” key 472 may be used torequest recording options, and the “C” key 473 may be used to request arecording schedule.

Video corresponding to the television channel to which the DHCT 200 iscurrently tuned (for which audio may also be playing, and whichtypically corresponds to a video presentation occupying the full screenbefore the user is presented with RPL screen 800) is displayed in avideo area 830. Next to the video area 830 is a detailed focus area 810that includes detailed information for a currently highlighted recordingentry 820. In the current example, the currently highlighted recordingentry 820 corresponds to the video presentation title JAG 822. Thedetailed focus area 810 may include information such as the title of thevideo presentation (e.g., JAG), the quality of the recording (e.g.,Good), the anticipated end of the recording duration (e.g., untilerased). A user may request additional information by activating theInfo key 432 on the remote control device 400.

In one embodiment, the detailed focus 810 area may include an icon or aletter (e.g., A or D) to indicate whether the video presentation wasreceived as an analog or digital signal. Furthermore, the PVRapplication 277 (FIG. 2) may identify a quality of a recording to a userbased on a parameter that was employed by the compression engine 217 incompressing an analog signal or based on a bit-rate of a receiveddigital signal.

FIG. 9 depicts a non-limiting example of a Record Options screen 900that contains a list of options 902 related to the recording and/orbuffering and of video presentations. A user may request the RecordOptions screen 900 by, for example, activating the “B” key 472 (FIG. 4)while being presented with the RPL screen 800 (FIG. 8). In this example,the list of options 902 includes an option 911 to sort recordedprograms, an option 912 to manage a time shift buffer, and an option 913to change recording settings. As suggested in the bottom area 850, theuser may activate the “C” key 473 (FIG. 4) in order to return to thepreviously displayed screen (e.g., the RPL screen 800). The detailedfocus area 810 provides information related to the currently highlightedoption 912. In an alternative embodiment, a Record Options screen 900does not include the video area 830 or the detailed focus area 810,and/or is presented as a barker that overlays a preceding screen (e.g.,the RPL screen 800).

FIG. 10 depicts a non-limiting example of a Buffer Management screen1000 that contains a list of options 1002 related to the buffering ofvideo presentations. A user may request the Buffer Management screen1000 by, for example, selecting option 912 while being presented withthe Record Options screen 900 (FIG. 9). Alternatively, the BufferManagement screen 1000 may be requested via the activation of adedicated key on a remote control device. In this example, the list ofoptions 1002 includes an option 1011 to view a list of bufferedprograms, an option 1012 to manage a time shift buffer, and an option1013 related to inter-channel buffering. These options 1011-1013 will bediscussed in more detail below.

FIG. 11 depicts a non-limiting example of a Buffer Size screen 1100 thatcontains a list of buffer size options 1102 for determining the size ofone or more time shift buffers (TSBs). A user may request the BufferSize screen 1100 by, for example, selecting option 1012 while beingpresented with the Record Management screen 1000 (FIG. 10). In thisexample, the list of buffer size options 1102 includes a 30 minutebuffer size option 1111, a 1-hour buffer size option 1112, and a 2-hourbuffer size option 1113. Other buffer size options may be displayed byscrolling up or down the list of buffer size options 1102. Selecting abuffer size option causes one or more TSBs to have a storage capacitythat can accommodate a video stream having a play time indicated by theselected option.

FIG. 12A depicts a non-limiting example of an Inter-Channel Bufferingscreen 1200 that can be used to activate or de-activate inter-channelbuffering. As used herein, inter-channel buffering refers to the abilityto access a buffered video stream corresponding to a previously tunedtelevision channel after effecting a change in television channels. Auser may request the Inter-Channel Buffering screen 1200 by, forexample, selecting option 1013 while being presented with the RecordManagement screen 1000 (FIG. 10). A user may activate inter-channelbuffering by selecting the “ON” option 1201 and may de-activateinter-channel buffering by selecting the “OFF” option 1202. In oneembodiment, even after the “OFF” option 1202 is selected, a user maysubsequently press the buffer key 436 (FIG. 4) prior to changing TVchannels in order to activate inter-channel buffering with respect tothe currently displayed channel.

FIG. 12B depicts a non-limiting example of an Inter-Channel Bufferingscreen 1210 that can be used to activate or de-activate inter-channelbuffering. The Inter-Channel Buffering screen 1210 is an alternativeembodiment to the Inter-Channel Buffering screen 1200 (FIG. 12A). A usermay request the Inter-Channel Buffering screen 1200 by, for example,selecting option 1013 while being presented with the Record Managementscreen 1000 (FIG. 10). A user may activate inter-channel buffering byselecting the option 1212 and may de-activate inter-channel buffering byselecting option 1212. Furthermore, the user may activate inter-channelbuffering only with respect to “favorite” TV channels or videopresentations by selecting option 1213.

A favorite channel or presentation may have been identified as such viauser input. A list of favorite channels and/or presentations may bestored in a favorites database 374 (FIG. 3). Selecting option 1213enables a user to access a buffered video stream corresponding to apreviously displayed channel after the user changes television channels(e.g., via the Channel +/−key 434), only if the previously displayedchannel or presentation had been designated as a “favorite.”

Inter-channel buffering with respect to only favorite channels orpresentations may be implemented by the PVR application 277. Forexample, after a user requests a change in television channels, the PVRapplication 277 may first access an IPG database 372 (containing atelevision program schedule) (FIG. 3) to identify the currentlydisplayed channel or presentation. The PVR application may then access afavorites database 374 to determine whether the currently displayedchannel or presentation had been designated as a favorite. If thecurrently displayed channel or presentation had been designated as afavorite, then the PVR application 277 may enable the user to access abuffered video presentation corresponding to the favorite channel orpresentation after a change in television channels is implemented.Otherwise, the PVR application 277 disables access to the buffered videopresentation corresponding to the channel that was displayed prior to achange in channels.

FIG. 13A depicts a non-limiting example of an Buffered Programs List(BPL) screen 1300 that contains a list of buffered video presentations.A user may request the BPL screen 1300 by, for example, selecting option1011 while being presented with the Record Management screen 1000 (FIG.10). Alternatively, the BPL screen 1300 may be requested via theactivation of a dedicated key on a remote control device.

A buffered programs list 1306 contains buffer entries corresponding tobuffered video presentations. Each buffer entry in the buffered programslist 1306 includes information such as the title of a buffered videopresentation, the broadcast time of the original video presentation, theavailable time of the buffered video presentation (i.e., the beginningand end times of the buffering), and an indication as to whether thebuffered video presentation is designated to be recorded (i.e., storedas a long-term recording). In one embodiment, the arrow keys 410 (FIG.4) can be used to scroll through the buffered programs list 1306 and tohighlight a desired buffer entry.

The bottom area 850 of BPL screen 1300 contains information about thecurrent functions of relevant keys on the remote control device 400. Assuggested in bottom area 850, the play key 421 and the record key 426may be used to request the playing and recording, respectively, of avideo presentation corresponding to a currently highlighted buffer entry1302. The “A” key 471 may be used to request the recording of all thebuffered video presentations, the “B” key 472 may be used to request aUI screen for sorting the buffered video presentation, and the “C” key473 may be used to “exit” from the BPL screen 1300.

FIG. 13B depicts a non-limiting example of an Buffered Programs List(BPL) screen 1310 that may be presented to a user in response to theactivation of the record key 426 (FIG. 4) while being presented with theBPL screen 1300 (FIG. 13A). As shown in FIG. 13B, the highlighted entry1302 indicates, as shown at 1324, that the buffered video presentation“News at 11” 1322 is designated to be recorded. As soon as the userconfirms this designation (e.g., by activating the “C” key 473 (FIG.4)), then the buffered video presentation “News at 11” 1322 is stored asa long-term recording.

FIG. 14 depicts a non-limiting example of a Sort screen 1400 thatcontains a list of options 1402 for sorting a list of buffered programs(e.g., the buffered programs list 1460 shown in FIG. 13). A user mayrequest the Sort screen 1400 by, for example, activating the “B” key 472(FIG. 4) while being presented with the BPL screen 1300 (FIG. 13A). Inthis example, the list of options 1402 includes options 1411, 1412, and1413 for sorting a list of buffered programs based on broadcast time,title, and buffered length (e.g., play time), respectively. By selectingone of the options 1411-1413, the user is presented with a list ofbuffered programs that are sorted accordingly (i.e., by broadcast time,title, or buffered length). Additional sorting options may also beselected by using the up and down arrows 411 and 412 on the remotecontrol device 400 to browse through the list of options 1402 and bythen using the select button 420 to select a desired sorting option.Additional sorting options may include, for example, an option forsorting a list of buffered programs based on their theme (e.g., comedy,drama, action, etc.).

FIGS. 15A, 15B, and 15C depict non-limiting examples of Sorted BufferedPrograms List (SBPL) screens 1500, 1510, and 1520, respectively. TheSBPL screen 1500 contains a buffered programs list 1306 that is sortedalphabetically by title. A user may request the SBPL 1500 by, forexample, selecting the title option 1412 while being presented with theSort screen 1400 (FIG. 14).

As shown in FIG. 15B, the SBPL screen 1510 contains a buffered programslist 1306 that is sorted based on the play-time duration of the bufferedvideo presentations. As a result, a buffered video presentation that hasa longer play-time is listed above another video presentation that has ashorter play-time. A user may request the SBPL 1510 by, for example,selecting the buffered length option 1413 while being presented with theSort screen 1400 (FIG. 14).

As shown in FIG. 15C, the SBPL screen 1520 contains a buffered programslist 1306 that is sorted based on the broadcast time of the bufferedvideo presentations. In other words, a video presentation that has anearlier start time is listed above another video presentation that has alater start time. A user may request the SBPL 1520 by, for example,selecting the broadcast time option 1411 while being presented with theSort screen 1400 (FIG. 14).

In an alternative embodiment, a UI screen for achieving functionalitydescribed herein may have fewer, additional, and/or different componentsand/or may have a different layout than is shown in FIGS. 8-15. Forexample, in accordance with one embodiment, among others, a UI screenmay not include a video area 830, a heading area 802, a detailed focusarea 810, and/or a bottom area 850.

It should be emphasized that the above-described embodiments of theinvention, particularly any “preferred embodiments”, are merely possibleexamples, among others, of the implementations, setting forth a clearunderstanding of the principles of the invention. Many variations andmodifications may be made to the above-described embodiments of theinvention without departing substantially from the principles of theinvention. All such modifications and variations are intended to beincluded herein within the scope of the disclosure and invention andprotected by the following claims.

1. A method, comprising: providing a first user interface that providesa list of buffered video presentations; enabling a user to order thelist according to buffering activity of each of the buffered videopresentations; receiving user input corresponding to ordering the listaccording to buffering activity; and responsive to receiving the userinput, ordering the list based on the buffering activity of eachbuffered video presentation.
 2. The method of claim 1, wherein thebuffering activity comprises buffered length of each of the bufferedvideo presentations.
 3. The method of claim 2, further comprisingproviding a second user interface that provides the ordered list ofbuffered video presentations.
 4. The method of claim 3, wherein orderingcomprises sorting based on play-time duration of each of the bufferedvideo presentations.
 5. The method of claim 4, wherein orderingcomprises presenting a first title of the buffered video presentationshaving a first play time duration above a second title having a secondplay-time duration different than the first play time duration.
 6. Themethod of claim 1, wherein the buffering activity comprises start timeof each of the buffered video presentations.
 7. The method of claim 6,further comprising providing a third user interface that provides theordered list of buffered video presentations.
 8. The method of claim 7,wherein ordering comprises sorting based on broadcast time of each ofthe buffered video presentations.
 9. The method of claim 7, whereinordering comprises presenting a first title of the buffered videopresentations having a first start time above a second title having asecond start time different than the first start time.
 10. A method,comprising: providing a first user interface that provides a list ofbuffered video presentations; enabling a user to order the listaccording to buffered length of each of the buffered videopresentations; receiving user input corresponding to ordering the listaccording to the buffered length; and responsive to receiving the userinput, ordering the list based on the buffered length of each bufferedvideo presentation.